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SYSTEMS MFD METHODS PROVIDING INTERACTIONS BETWEEN MULTIPLE 
SERVERS AND AN END USER DEVICE 

Field of the Invention 
5 The invention relates to systems and methods which 

provide interactions between multiple servers and an end user 
device, for example for application to connectivity issues such 
as authentication. 

10 Background of the Invention 

Client-side software, such as a web browser, uses 
some commonly agreed upon procedures to determine whether 
identifiers for any two servers, or network devices, are in the 
same network community called a domain (single domain) . If 

15 they are not in the same domain, the two network devices are 
said to be in different domains (multiple domains) 

For security purposes, servers which provide WWW 
(world wide web) content often require users to complete an 
authentication procedure before being provided access to a 

2 0 particular resource. After completion of such an 

authentication, the server sends the user's web browser one or 
more "cookies" which the browser then stores in a "cookie jar" 
for the particular domain. At a later time, if the user 
attempts to access the particular domain again, the web browser 
25 automatically forwards the cookies stored in the domain's 

cookie jar, and the server recognizes these cookies and does 
not require the user to re-authenticate. These cookies provide 
a pre-validated, sometimes time-limited ticket to access one or 
more protected web sites in a domain. 

3 0 It is frequently the case that an organization or a 

group of participating organizations might provide service to 
users through miiltiple different domains, each of which have 
their respective authentication procedure which must be 
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completed by a user. Disadvantageously , a user who completes 
the authentication procedure for a first domain who later 
visits a second of the multiple domains will need to complete a 
subsequent authentication procedure, and this is inconvenient 
5 to the user. It would be desirable to allow a user to 
authenticate within one domain, and then not need to re- 
authenticate in other related domains. 

More generally, it may be desirable to communicate 
user-specific information, for example personal data and/or 

10 purchase enablingf information pertaining to a user from one 
server to another. Communicating such information through 
direct server- to- server communications may be in violation of 
some countries' privacy laws. For example, sending credit card 
information, street address, telephone number, social security 

15 number, bank detciils, personal health information, taxation 
data, criminal records etc. from one server to another server 
directly without user consent may be a violation of privacy 
laws . Another ap3proach is to send multiple secured emails to 
different sites with registration information. The information 

20 is sent in a non -validated one-way communication. 

In the conventional use of a browser as master, data 
is acquired from a server. The browser may also "post" data to 
a server, e.g. when a user fills out a form, after which the 
browser delivers data to the server which provided the form. 

2 5 This does not provide a convenient way to transfer data between 

servers . 

Summary of the Invention 

The invention, in accordance with one broad aspect, 

3 0 provides a method of conveying access control information, 

including but not limited to cookies, identification, 
authentication, authorization and privilege information from 
one network device to another network device through an end 
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user device, for example in a system in which two servers and 
an end user device are all connected to the Internet, 
optionally after performing an authentication on an initial 
access request in the event the network device is the first 
5 accesses . The method starts after the one network device 

receives a message from the end user device. The one network 
device in response to this message from the end user device 
sends a response message to the end user device containing the 
access control information to be conveyed to the another 

10 network device. The response message also contains an 

instruction or instructions which cause the end user device to 
send a second message to the another network device containing 
at least part of the access control information. The access 
control information is preferably contained in a content 

15 portion of the response message. 

In the event the method is being implemented by the 
first network device accessed by the end user, in which case 
the network device will be referred to as the "initial network 
device", the first message has a header portion and a content 

2 0 portion, and the access control information is contained in the 
header portion which is extracted for use in the response 
message . 

In the event the method is being implemented by any 
other network device than the initial network device, the first 

2 5 message has a header portion and a content portion, and the 

access control information is contained in the content portion, 
and the method further involves extracting the access control 
information from the content portion for use in the response 
message . 

3 0 Optionally, the response message is used to contain 

user-specific information together with instructions to include 
at least part of the user-specific information in the second 
message. When this is done, an option might be presented to 
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the end user device to change and/or delete any of the user- 
specific information before sending the message to the another 
network device . 

Preferably, each network device is further adapted to 
5 function as an initial network device. Such an initial network 
device is adapted to receive an initial access request from the 
end user device to access a protected resource on the initial 
network device, and to perform an authentication process to 
determine if access should be granted and if so, to respond 

10 with an access response message specifying the access control 
information in association with the domain of the initial 
network device and causing the end user device to send the 
first message. On an ongoing basis after this, subsequent 
access is allowed to the protected resource to requests 

15 containing the access control information. 

The invention in accordance with another broad aspect 
provides a network device implemented method in which a network 
device responds to an initial access request with a redirect 
message instructing a redirection to a MDSSO (multi -domain 

2 0 single sign-on) function on the network device, the redirect 
message also specifying access control information in a header 
of the redirect message. The MDSSO function receives an input 
message having a header portion and a content portion, with the 
input message containing the access control information 

2 5 embedded within the header portion. The MDSSO function 

responds with a response message having a header portion and a 
content portion, with the response message containing the 
access control information in the header portion and having the 
content portion containing the access control information and 

3 0 also containing instructions to send a subsequent message to 

another network device on a different network domain, the 
subsequent message having a content portion containing at least 
part of the access control information. 
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Another broad aspect of the invention provides a 
network device having an authentication front end and an MDSSO 
function, the network device being adapted to provide initial 
network device functionality upon receipt of a request message 
containing access control information only in a header portion, 
and adapted to provide non- initial network device functionality 
upon receipt of a request message containing access control 
information in both a header portion and a content portion. 

In providing the initial network device 
functionality, the authentication front end is adapted to 
process an initial access request message from an end user 
device to access a protected resource on the network device by 
performing an authentication process to determine if access 
should be granted and if so, responding with an access response 
message specifying an access control information in association 
with the domain of the network device and causing the end user 
device to send a first request message to an MDSSO (multiple 
domain single sign-on) function on the network device 
specifying the access control information in a header portion 
of the first request message. Also in providing the initial 
network device f \anctionality, the MDSSO function is adapted to 
process a request message directed to it containing access 
control information only in a header portion by extracting the 
access control information from the header portion and sending 
to the end-user device a response message containing the access 
control information in a header portion and having a content 
portion containing the access control information and also 
containing instructions to send a subsequent request message to 
another network device on a different network domain, the 
subsequent message having a content portion containing the at 
least part of access control information. 

In providing non- initial network device 
functionality, the MDSSO function is adapted to process a 
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request message directed to it containing access control 
information in a content portion by extracting the access 
control information from the content and sending to the end- 
user device a response message containing the access control 
5 information in a header portion and having a content portion 
containing the access control information and also containing 
instructions to send a subsequent message to another network 
device on a different network domain, the subsequent message 
having a content portion containing at least part of the access 

10 control information. 

A hidden form may be used in the response message and 
the second message to contain the information. Optionally, the 
end user may be presented with an option to send the second 
message or not. The instructions to send to the second network 

15 device may consist of custom content within the response 
message's content portion. 

When an authentication function is also to be 
provided the network device performs authentication on an 
initial access request and then responds to the initial access 

2 0 request with a redirect message instructing a redirection to a 
multi -domain single sign-on function on the network device 
which is responsible for executing the steps of receiving an 
input message, extracting the cookie, and responding with a 
response message. 

2 5 Since presumably the user wants to get back to the 

original network device it accessed, the method preferably 
redirects the user back to the original network device if there 
is no subsequent network device to be involved in the method. 
Another embodiment provides a multi-domain single sign-on 

3 0 system consisting of a group of network devices adapted to 

implement any of the methods described herein. 

Advantageously, with any of the above methods the 
content and redirection information contained in the content 
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portion of messages may be protected by cryptographic means as 
known in the art, for example through encryption, digital 
signature, message authentication codes, etc. the protection 
may be by way of a protected communication channel (e.g. Secure 
5 Socket Layer or Transport Layer Security as known in the art) , 
or by protecting the data directly, independent of the 
communication channel. 

In the event the HTTP/HTML environment is used, the 
various messages may be HTTP Request messages and HTTP Response 
10 messages. 

The invention also provides a network device adapted 
to implement the above methods described herein, and an article 
of manufacture consisting of a computer usable medium having 
computer readable program code means embodied therein for 
15 implementing any of the methods described herein and a computer 
data signal embodied in a transmission medium having source 
code segments adapted to implement any of the methods described 
herein. 

By using the content portion of messages to perform 

2 0 the above methods, great flexibility is realized. For example 

the content portion has no size restrictions in current 
implementations in contrast to the header portions which is 
typically size restricted. The content can be anything (e.g. 
HTML, Javascript, Java Applet) . This provides opportunities 
25 for interpretation and intervention. A new content-type that 
can be interpreted by custom software at the client, or more 
user interaction via HTML/ Javascript can be provided rather 
than passing things on invisibly. 

More specifically, in one embodiment, information is 

3 0 put in the content portion to create custom content, which is 

then "interpreted" by new software at the browser which opens 
the custom content, processes it (e.g. via JavaScript) to 
determine the next server to visit, and visits the next server 
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e.g. by sending a POST message. This is analogous to the 
"opening" of the content data and processing it to determine 
the server to vissit (analogy: opening and reading a letter) . 

Using these methods the initial network device and 
5 any subsequent network device can serve as a point of 
validation (e.g. username/password) and may repackage 
information for a client to send to others. 

It is noted that the information provided to an end 
user device by an initial network device may be a superset of 
10 the access control information contained in the response 

message at least a part of which is to be forwarded on to the 
subsequent network device. Thus there may be a first set of 
information provided to the end user device by the initial 
server some or all of which may relate to access control, all 
15 or a subset of which is to be forwarded to a subsequent network 
device, this subset functioning as the "access control 
information" for the purpose of this description. 

Another broad aspect of the invention provides a 
method of conveying user-specific information from one network 

2 0 device to another network device on a different domain through 

an end user device. The method is very similar to the above 
described methods of circulating access-control information, 
and is preferably combined with those methods. In this method, 
the one network device in response to a first message received 
25 from the end user device containing user- specif ic information, 
sends a response message to the end user device containing the 
user-specific information, the response message being adapted 
to cause the end user device to send a second message to the 
another network device containing at least part of the user- 

3 0 specific information after presenting an option to the end user 

device to change and/or delete any of the user- specif ic 
information. The response message has a header portion and a 
content portion and the response message contains the user- 



specific information and a network device identifier for the 
another network device embedded within its content portion. 
The second message has a header portion and a content portion 
and the second message contains the at least part of the user- 
specific information embedded within its content portion. 

Brief Description of the Drawings 

Preferred embodiments of the invention will now be 
described with reference to the attached drawings in which: 

Figure 1 is a block diagram of an example system 
employing an embodiment of the invention; 

Figure 2 is a block diagram of an MDSSO (multiple 
domain single sign-on) server of Figure 1; 

Figure 3 is a flowchart of the functionality of the 
authentication front end of Figure 2; 

Figure 4 is an example HTTP Response message used to 
redirect an end user device's browser to an MDSSO server; 

Figure 5 is a flowchart of the functionality of the 
MDSSO server of Figure 2 ; 

Figure 6 is an example HTTP Response message used by 
the MDSSO server to redirect an end user device's browser to a 
subsequent MDSSO server; 

Figure 7 is a flowchart of the steps executed at the 
browser in response to messages received from the MDSSO server; 
and 

Figure 8 is a block diagram of a system for 
implementing another embodiment of the invention. 

Detailed Description of the Preferred Embodiments 

Figure 1 is a block diagram of an embodiment of the 
invention used to provide a multiple domain single sign-on 
functionality. An. end user device 10 is shown connected to a 
data network 12 (typically through a service provider, not 
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shown) to which is also connected a number of MDSSO {multiple 
domain, single sign-on) servers 14,16,18 on different domains. 
The MDSSO servers 14,16,18 are servers which have been adapted 
to participate in a shared authentication process provided by 
5 this embodiment of the invention whereby after a user 

authenticates with a single one of the MDSSO servers, the user 
will subsequently be permitted access to any of the MDSSO 
servers without being required to re-authenticate. There would 
typically be other servers such as server 2 0 which are 

10 conventional servers not adapted to participate in the shared 
authentication process, or which might be part of another 
unrelated group of MDSSO servers. In the illustrated example, 
MDSSO servers 14,16,18 have domain names www.domain_A.com, 
www.doraain_B.com and www.domain_C.com respectively. The set of 

15 domains for which this multiple domain, single sign-on is 
performed will be referred to as an MDSSO group. This 
typically will be a list of server domain names. Typically a 
single MDSSO cookie provides access to all the URLs of a domain 
(uniform resource locators) . More generally each cookie can 

2 0 provide access to particular resources available at a network 
device . 

The invention can be applied in the context of the 
Internet in which case the data network 12 is the Internet. 
More generally the data network 12 could be any suitable 

25 network over which the end user device 10 is to be connectable 
to the MDSSO servers 14,16,18, such as a WAN (wide area 
network) or LAN (local area network) for example. The end user 
device 10 is a device capable of connecting to and 
understanding the MDSSO servers 14,16,18 through the data 

30 network 12. For example, in the event the MDSSO servers 

14,16,18 use HTTP/HTML, the end user device might be any device 
capable of understanding the HTTP protocol and of interpreting 
HTML. For example, it might be a personal computer equipped 
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with a web browsing application (hereinafter browser) , a mobile 
phone or some other Internet appliance. 

In the example implementation described below, the 
assumption is made that the data network 12 is the Internet, 
5 and that HTTP is the protocol of choice with the end user 
device 10 being equipped with a browser 11. 

The details of the MDSSO servers 14,16,18 are shown 
in Figure 2 . Each MDSSO server has an authentication front end 
22 and also has a MDSSO (multi-domain single sign-on) function 
10 24 . 

The purpose of the authentication front end 22 is to 
coordinate the collection and verification of authentication 
information from a user requesting access to the server or to a 
particular protected resource. The details of an example 

15 method which might be implemented by the authentication front 
end 2 2 will be described with reference to Figure 3. Whenever 
a user requests to access a protected URL, the header of the 
request is checked by the authentication front end 22 for a 
valid cookie or cookies. If these are not present, the 

2 0 authentication front end 22 proceeds with an authentication 
process described below. 

Typically, the authentication front end 22 receives 
initial requests, for example an HTTP Request, to access a 
protected URL (step 3 -A) . In the event the request contains 

25 valid cookies (Yes path, step 3-B) then access is granted to 
the protected URL (step 3-C) . In the event the request 
contains no cookies or invalid cookies, the user is sent an 
authentication form to fill in (step 3-D) . In response to 
this, the authentication front end 22 receives the completed 

30 authentication form (step 3-E) , and does validation on the 
authentication information filled in by the user (step 3-F) . 
If invalid, the access request is rejected (step 3-F) . 
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In conventional authentication systems, after 
successful authentication a cookie sent back to the users is 
typically accompanied by a redirect instruction to another 
page, typically the protected page that the user initially 
5 requested or a successful authentication page. According to 
this embodiment of the invention, the authentication front end 
22, after successful validation, generates an MDSSO cookie and 
sends this back to the user in the header portion of a message 
which also redirects the user's browser to access the server's 

10 MDSSO function 24, for example in an HTTP Response message 

(step 3-G) . When a browser, such as browser 11, receives the 
cookie, it stores it in association with the server domain 
name, and then includes it in any subsequent requests to that 
server. An MDSSO cookie is a cookie which is valid at each of 

15 the domains in the MDSSO group. An example of such a message 
is shown in Figure 4 where it has been assumed that MDSSO 
server 14 with domain name www.domain_A.com received the 
request. The HTTP Response message has a header 40 and in this 
example an empty content portion 42. The header 40 specifies 

2 0 the MDSSO cookie 41, for example using the format: 

Set-Cookie: <mdsso cookie name> = <mdsso cookie value>; expires<DATE>; 

path = /; domain = <domain name> 
to specify a cookie with some name, <mdsso cookie name> and to 
have a value <mdsso cookie value>. The cookie specifies the 
25 domain with which it is associated (<domain name>) , and the 
cookie may also have an expiry date (DATE) . The header also 
has a redirect 43 to the MDSSO function (more generally some 
network resource address), specified using the format: 

"Locatio.n:http://www.domain_A.com/servlet/mdsso" 

3 0 where the MDSSO function, named "mdsso" must be made 

accessible in the manner prescribed. After the generation of 
this message, the authentication front end's responsibilities 
are over. The MDSSO function 24 of each of the MDSSO servers 
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is not a protected function/URL, so no authentication is 
performed when any one of the MDSSO functions 24 is 
subsequently accessed. 

In the described implementation, forms are used in 
5 the authentication process. This is just one of many ways to 
authenticate. Others include entering a user name/password 
combination through a dialog, or client certificate 
authentication as known in the art, or through the use of a 
passcode from a one-time passcode generator. The MDSSO 

10 functionality is not affected by the form of authentication 

that is used. Furthermore, the MDSSO functions and methods on 
their own without any authentication are useful. 

The functionality of the MDSSO function 24 will now 
be described in detail with reference to Figure 6 and to the 

15 flowchart of Figure 5. By way of overview, the MDSSO function 
24 on each MDSSO server uses an HTTP Response message to cause 
the browser 11 to fill up its cookie jar for the server's 
domain and to direct the browser 11 to send a message having 
hidden content (data which is downloaded but not displayed to 

2 0 the user, for example hidden content in an HTML page) to the 
next domain in a sequence of domains . A preferred format for 
such an HTTP Response message is shown in Figure 6. The 
message includes a header portion 60 and a content portion 62 . 
The header portion 60 again specifies the MDSSO cookie using 

25 the format indicated above. The MDSSO cookie is used by the 

b^rowser 11 to fill up its cookie jar for the domain responding. 
The content portion 62 is intended for processing by the 
browser 11. The content portion includes a client-side 
javascript 64 which is run when the HTML <body> is loaded by 

30 the client. An example of such a script 64 is shown in Figure 
6 and reproduced below: 
<head> 
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<script language = "javascript"> 
function doMDSSOQ { 
document.forms[0].sulbmit(); 
} 

5 </script> 
</head> 

<body language = "javascript" onload = "doMDSSO()"> 

A hidden form 66 is also embedded in the content 
portion 62 with hidden values as shown in Figure 6 and 
10 reproduced below: 

<form method-'post" action="<next server name>/servlet/mdsso" name="mdsso" 
<input type = "hidden" name = "<mdsso cookie name>" value = "<mdsso cookie 

value>"> 

<input type = "hidden" name = "homeServer" value = "<home server name>"> 
15 <input type = "hidden" name = "homeURL" value = "<home URL>"> 

<input type = "hidden" name = "Servers Visited" value = "<list of servers>" 
</form> 

The form includes a line 68 specifying the MDSSO cookie name 
and MDSSO cookie value. The form includes a line 70 specifying 
2 0 the name of the home server. The home server is the server 

initially accessed by the user, and to which the user should be 
returned at the end of the process. The form includes a line 
72 specifying the URL on the home server to which the user is 
to be directed at the end of the process. This is typically 

2 5 the first protected URL visited by the user or some sort of 

successful login page. The form includes a line 69 indicating 
the post action of the form, specifying the particular server 
(<next mdsso server name>) (more generally specifying a network 
device identifier - anything allowing a determination of where 

3 0 to send the message) to which the form is to be sent. The form 

may include a line 74 specifying the sequence of servers which 
have been visited thus far. While the content portion in the 
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above description includes Javascript, any suitable form of 
embedded executable content may be used. 

Referring now to Figure 5, the MDSSO function 24 is 
activated upon receipt of a message, for example an HTTP 
Request message, directed to it (step 5-A) . The first thing 
the MDSSO function 24 does is determine if the HTTP Request 
specifies a MDSSO cookie in its header (step 5-B) . This will 
only be the case when the user's browser 11 is responding to 
the initial redirect from the authentication front end 22. In 
the event there is a MDSSO cookie, processing continues as 
described further below. 

In the event there is no MDSSO cookie, the MDSSO 
function 24 processes the content portion of the HTTP Request 
if any (step 5-C) . If there is no content portion, or if the 
content is invalid, a response containing a redirection to an 
authentication peige is sent (step 5-D) . Examination of the 
content field may involve decrypting the content field if 
encryption was employed. 

In the event there was an MDSSO cookie in the header, 
or there was a content field containing a MDSSO cookie, the 
MDSSO function 24 identifies if there are any more domains to 
be included in the MDSSO (step 5-E) . For example, the MDSSO 
function 24 might compare its own server name with the home 
server field in line 70 of the hidden form 66, and if these 
match, it will know that it is time to redirect to the home 
URL. If there is a further domain to visit, the MDSSO function 
24 determines the next domain which is to participate in the 
MDSSO (step 5-F) . The MDSSO function 24 then generates an HTTP 
Response with a header 60 and a content portion 62, the content 
being encrypted if appropriate. The header 60 contains the 
MDSSO cookie as received in the header, or as extracted from 
the content portion of the HTTP Request message. The domain 
name specified in the header specifies the server in the MDSSO 
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group in association with which the MDSSO cookie is to be 
stored. The content includes the hidden form 66 specifying the 
next domain, and also contains the MDSSO cookie. The HTTP 
Response message thus generated is sent to the user (step 5-G) . 
In the event the particular domain is the last domain to be 
processed (No path, step 5-E) , the response header contains the 
MDSSO cookie and specifies the redirection to the original home 
URL (step 5-H) . 

The browser 11 is preferably a standard browser which 
is capable of processing HTTP Responses and generating HTTP 
Requests in accordance with accepted standards. The behaviour 
of the browser 11 is for the most part reactive, with the 
exception of the initial authentication and will now be 
described with reference to Figure 7. The whole process is 
instigated when a user requests access to a protected resource 
on an initial MDSSO domain for the first time (or after the 
expiry of any cookies) (step 7 -A) . In response to this 
request, the browser 11 receives an authentication form which 
it presents to the user for completion (step 7-B) and which is 
then returned to the MDSSO server (step 7-C) . Assuming 
successful authentication, the browser receives an HTTP 
Response message specifying an MDSSO cookie, and also 
redirecting the browser to access the MDSSO function (step 7-D) 
in the server. The browser 11 stores the MDSSO cookies in the 
cookie jar for the initial MDSSO server (step 7-E) , and sends 
an HTTP Request to the MDSSO function on the MDSSO server in 
accordance with the redirect (step 7-F) . Since the cookie jar 
for the MDSSO server contains cookies, these will be included 
in this HTTP Request. In response to this, the browser 11 will 
receive another HTTP Response containing a hidden form which 
includes the MDSSO cookies, and also containing instructions to 
post the hidden form to the next MDSSO server (step 7-G) which 
the browser then does (step 7-1) . The sequence of steps of 
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receiving a hidden form (step 7-G) and posting it to the next 
server (7-1) are repeated for each server. Each time a hidden 
form is received, the MDSSO cookies are specified, and the 
browser stores the MDSSO cookies in the cookie jar for the 
5 server from which the form was received (step 7-H) . Of course, 
for the first hidden form which is received from the initial 
MDSSO server, these cookies will have been previously stored in 
the cookie jar for that domain. Eventually, a redirect to the 
home URL will be received (step 7 -J) in response to which the 

10 browser 11 sends a request to the home URL (step 7-K) 
completing the process. 

In the above example, the next server to be visited 
as specified in the content portion, must be known at the 
server presently being visited. More generally, any convenient 

15 mechanism for specifying a group, or sequence of MDSSO servers 
to be visited may be employed. Each MDSSO server might have 
locally stored information specifying a next server, or 
alternatively, the HTTP Request message it receives might 
either specify the next server or contain information allowing 

2 0 the next server to be identified. 

One approach is to pre -store information at each 
server, specifying a ''next server" in a virtual list. This 
approach might be more secure than the method identified below, 
but might make it harder to update the list and/or add server 

2 5 components. 

Another approach is to include in the HTTP response 
messages generated by the MDSSO function an ordered list (e.g. 
domain_A, domain_B, domain_C) of servers to visit. A given 
server finds itself in the list, and causes the browser to 

3 0 visit the next server in list (sending list along) . This 

approach can be enhanced by sending on only the un-used tail 
end of the list. This approach may prove better than the first 
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approach for situations where the servers are not maintained by 
one company. 

Server To Server Information Transfer 

The above description has focussed upon an embodiment 
which provides an MDSSO solution. More generally, another 
embodiment of the invention provides a method for causing an 
end user device to visit a number of different communications 
devices, and optionally to transfer data across a series of 
communications devices (e.g. across a series of servers) 
without any direct server- server communication. 

With this embodiment, HTTP (and other communications 
protocols) may be used to achieve the result of a browser 
communicating data among a series of servers. The data 
transferred between servers is in the content portion of the 
message may be selectively protected from exposure unlike the 
header . 

This may be either done transparently to the end- 
user, or by presenting a choice to browser user of whether to 
allow use of the browser to perform this action. This choice 
can be presented via another browser window or dialog if for 
example Javascript is used. Optionally the capability to 
change data before sending can also be provided. The choice 
might depend on the application/data and other issues (i.e. 
privacy legislation, consumer trust, feeling of being in 
control from a consumer perspective) . 

An example is shown in Figure 8 which is a network 
connectivity very similar to Figure 1, showing three servers 
100,102,104 connected to a data network 12 to which an end user 
device 10 running a browser 11 is also connected. The servers 
are labelled SERVER_1, SERVER_2 , and SERVER_3 . An 
authentication front end is not shown in each server 
100,102,104 (although one might be present), and instead of an 
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MDSSO function, each server is provided with a respective MDCB 
{multi-domain communications block) 106,108,110. Also shown in 
one of the servers 10 0 is a data source 112 from which the MDCB 
106 on that server is capable of collecting data for transfer 
to other servers. Alternatively the data might be collected 
from a user which has accessed the server. The other servers 
may also have data sources 114,116. 

In order to transfer data from one server to another 
server in a different domain, an approach similar to the above 
described MDSSO is used. When the end user device 10 accesses 
SERVER_1, the MDCB sends a response message containing data 
which it wants to send to another server, for example SERVER_2 , 
in the content portion of the message, and containing 
redirection instructions again in the content portion causing 
the browser to send a request message to SERVER_2 containing 
the data. The MDCB 10 8 on SERVER_2 is capable of extracting 
the data from the request. Data has thus been transferred from 
SERVER_1 10 0 to SERVER_2 102 without any direct contact between 
the servers. Of course, this could be continued to further 
servers, a chain of servers being identified using any 
convenient method such as any of the methods identified 
previously for MDSSO. Each time the MDCB returns the data to 
the browser, it might be the same data as from the previous 
server, or it might be modified data. 

In effect, this embodiment of the invention provides 
a method to turn a master-slave protocol into slave-master, 
without changing the protocol. For example, it may use the 
existing HTTP protocol in a manner which makes the browser a 
slave to the server and follows server commands. 

In the practical case of HTTP, a user can turn off 
the "browser as slave" functionality by disabling JavaScript, 
or using a setting whereby the user is prompted for approval 
before each cookie transfer. Alternatively, a new content type 
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can be created and custom software developed to interpret the 
content. The advantage of this approach is that the developer 
would not be limited to available browser features and could 
provide a richer experience for the user. This may employ 
5 custom software . 

The data being transferred between servers might for 
example be user-specific data. In this event, preferably, the 
end-user is given the opportunity to control which user- 
specific data is to be forwarded and to what servers. 

10 The above described method and system of transferring 

data between servers is combinable with the previously 
described methods and systems of providing multiple domain 
single sign-on to provide a method and system by which multiple 
domain single sicfn-on and server- to- server data transfer of 

15 such user-specific information can be achieved simultaneously. 
In this case, the messaging would include both the access 
control information (such as the MDSSO cookie for example) and 
the user-specific information. 

20 Register-once-shop-anywhere Example 

The following is an example implementation of the 
above embodiment which allows a user to register once at an 
online shop and then shop everywhere else in the same e-Mall 
(network of shops) without having to re-enter the same 

25 shipping/credit card information. 

Assume four shops (Shop_l, Shop_2 , Shop_3 , Shop_4) 
join an E-mall and agree to share registration/shipping/credit 
card info, but do NOT want to share a common backend user 
database . 

30 

Step-by- step walk through 

1. The user visits www.shop_l.com and fills in 
registration information including authentication information 
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and other user- specif ic information, for example shipping and 
credit card information (more generally any type of personal 
data and/or purchase enabling information) . 

2. The server validates the info and puts it in a 

5 hidden form (including user- specif ic information, if acceptable 
to users) all ready to send to the next server as described by 
the MDCB example above including the other sites in the E-Mail . 

3 . The user may be transparently redirected to the 
next site. Alternatively, instead of transparently re-directing 

10 the user to the next site, the user may be prompted with the 
choice to stop further forwarding, forward to remaining sites, 
or to select who to forward in remaining sites, and/or to 
control what user- specif ic information is forwarded on to other 
sites. This may be done with HTML/ Javascript or with custom 

15 client side software. 

Optionally, the redirect to the next server only 
happens upon successful registration at each server. Thus each 
server will have the opportunity to validate and request 
changes to the submitted information before passing it on. For 

2 0 example, a username/password may already be taken. 

Preferably, some standard data format should be 
agreed upon to pass the information from site to site. 
Furthermore, preferably this passing of confidential 
information should be done in a secure fashion, by using some 

2 5 sort of cryptographic means for example. Each one of these 

servers may then store this information in its own backend 
database . 

The following is an example of a Response message 
generated by a first server, Server_l, which gets an end user 

3 0 device involved in transferring two pieces of data (CreditCard 

number collected from user and CustomerLoyalty rating stored at 
Server 1) from the first server, to a second server, Server_2 
with a POST. 
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HTTP/1.1 200 OK 
Content-Type: text/html 
Content-Length: < 
<head> 

5 <script language="javascript"> 
function doMDCB(){ 
docunnent.forms[0].submit(): 
} 

</scnpt> 
10 </head> 

<body language-'javascript" onLoad="doMDCB()"> 

<form method="post" action="http://www.server_2.com/mdcb" name="mdcb"> 
<input type="hidden" niame="CreditCard" value="450012341234"> 
<input type="hidden" name="CustomerLoyalty" value="4"> 
15 <input type="hidden" name="homeServer" value="www.server_1 .com"> 
<input type="hidden" name- 'homeURL" value=7CustomLogonPage"> 
</form> 
</body> 

Thus, the browser is used as an agent to deliver data 

2 0 (identical, or modified) from one server to another, with no 

direct server-server communications. For example: browser, 
serverl, browser,, server2 , . . ., browser, server_n. 
(Optionally finish up at the browser also) . 

Numerous modifications and variations of the present 
25 invention are possible in light of the above teachings. It is 
therefore to be understood that within the scope of the 
appended claims, the invention may be practised otherwise than 
as specifically described herein. 

For example, the invention has been described with 

3 0 reference to particular examples including examples using 

cookies. More generally, the invention can be used with any 
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type of access control information, and not restricted, 
specifically to cookies. 

The invention has been described with reference to 
pairticular examples employing servers. More generally, any 
5 suitable network device may be used. Similarly, the invention 
has been described mainly with reference to end user devices 
equipped with web browsing functionality. More generally, any 
end user device adapted to have the required capabilities may 
be used. The servers and end user device might be connectable 
10 through the public Internet, and more generally through any IP 
based network, and more generally still through a network of 
any type . 

An embodiment of the invention has been described 
with reference to providing secure access to URLs in different 
15 domains. More generally, the embodiments of the invention 

relating to security can be applied to providing secure access 
to any type of network resource, for example, data, physical 
devices, web sitejs, etc. 
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WE CLAIM: 

1. A method of conveying access control information from 
one network device to another network device on a different 
domain through an end user device comprising: 

5 the one network device in response to a first message 

received from the end user device containing access control 
information, sending a response message to the end user device 
containing the access control information, the response message 
being adapted to cause the end user device to send a second 
10 message to the another network device containing at least part 
of the access control information; 

wherein at least part of the access control 
information is used to control access to a protected resource 
on at least one of the first and second network devices. 

15 

2. A method according to claim 1 wherein: 

the response message has a header portion and a 
content portion and the response message contains the access 
control information and a network device identifier for the 

2 0 another network device embedded within its content portion; 

the second message has a header portion and a content 
portion and the second message contains the at least part of 
the access control information embedded within its content 
portion. 

25 

3. A method according to claim 1 wherein: 

the first message has a header portion and a content 
portion, and the access control information is contained in the 
header portion, the method further comprising extracting the 

3 0 access control information from the header portion for use in 

the response message . 
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4. A method according to claim 1 wherein: 

the first message has a header portion and a content 
portion, and the access control information is contained in the 
content portion, the method further comprising extracting the 
5 access control information from the content portion for use in 
the response message. 

5. A method according to claim 2 wherein a hidden 
content is used in the response message to contain the access 

10 control information. 

6. A method according to claim 1 further comprising 
presenting an option to the end user device to send the second 
message or not. 

15 

7 . A method according to claim 2 wherein the response 
message's content portion is formatted as a custom content 
type. 

20 8. A method according to claim 2 wherein at least part 

of the content portion of the response message is protected by 
cryptographic means . 

9. A method according to claim 1 wherein the first 

2 5 message is an HTTP Request message, and the response message is 
an HTTP Response message. 

10 . A method according to claim 1 wherein the access 
control information is a cookie. 

30 

11. A method according to claim 1 further comprising: 
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containing user- specif ic information in the response 
message together with instructions to include at least part of 
the user-specific information in the second message. 

12. A method according to claim 11 further comprising 
presenting an option to the end user device to change and/or 
delete any of the user- specif ic information before sending the 
message to the another network device. 

13 . A method according to claim 1 wherein the one network 
device is an initial network device accessed by the end user 
device, the method further comprising: 

prior to sending the response message, 

a) the initial network device 
receiving an initial access request from the end user 
device to access a protected resource on the initial 
network device; 

b) the initial network device 
performing an authentication process to determine if 
access should be granted and if so, responding with 
an access response message specifying the access 
control information in association with the domain of 
the initial network device and causing the end user 
device to send the first message; and 

on an ongoing basis after performing the 
authentication process allowing subsequent access to the 
protected resource to requests containing the access control 
information. 

14. A method according to claim 13 further comprising: 
containing user- specif ic information in the response 

message together with instructions to include at least part of 
the user-specific information in the second message. 
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15. A method according to claim 14 wherein the user- 
specific information comprises at least one of purchase 
enabling information and personal data. 

5 

16. A method according to claim 15 further comprising 
requiring user acceptance before including the at least part of 
the user-specific information in the second message. 

10 17. A method according to claim 14 wherein at least part 

of the user-specific information is protected by cryptographic 
means . 

18. A network device implemented method comprising: 

15 a) a network device on a first network domain 

receiving an input message having a header portion and a 
content portion, with the input message containing an access 
control information embedded within the content portion; 

b) the network device responding with a 

2 0 response message having a header portion and a content portion, 
with the response message containing the access control 
information in the header portion and having a content portion 
containing the access control information and also containing 
instructions to send a subsequent message to another network 

25 device on a different network domain, the subsequent message 

having a content portion containing at least part of the access 
control information. 

19. A method according to claim 18 wherein the another 
30 network device is specified in the input message. 

20. A method according to claim 18 wherein the another 
network device is specified by the network device. 
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21,. A network device implemented method comprising: 

the network device responding to an initial access 
request with a redirect message instructing a redirection to a 
MDSSO (multi-domain single sign-on) function on the network 
device, the redirect message also specifying an access control 
information in a header of the redirect message; 

the MDSSO function receiving an input message having 
a header portion and a content portion, with the input message 
containing the access control information embedded within the 
header portion; 

the MDSSO function responding with a response message 
having a header portion and a content portion, with the 
response message containing the access control information in 
the header portion and having the content portion containing 
the access control information and also containing instructions 
to send a subsequent message to another network device on a 
different network domain, the subsequent message having a 
content portion containing at least part of the access control 
information. 

22. A method according to claim 21 further comprising 
performing an authentication process to determine if access 
should be granted, and if so responding to the initial access 
request message with the redirect message, and if not rejecting 
the initial access request. 

23 . A network device comprising an authentication front 
end and an MDSSO function, the network device being adapted to 
provide initial network device functionality upon receipt of a 
request message containing access control information only in a 
header portion, and adapted to provide non- initial network 
device functionality upon receipt of a request message 
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containing access control information in both a header portion 
and a content portion; 

wherein in providing the initial network device 
f unc t ional i ty : 

5 a) the authentication front end is adapted to process 

an initial access request message from an end user device to 
access a protected resource on the network device by performing 
an authentication process to determine if access should be 
granted and if so, responding with an access response message 

10 specifying an access control information in association with 
the domain of the network device and causing the end user 
device to send a first request message to an MDSSO (multiple 
domain single sign-on) function on the network device 
specifying the access control information in a header portion 

15 of the first request message; 

b) the MDSSO function is adapted to process a request 
message directed to it containing access control information 
only in a header portion by extracting the access control 
information from the header portion and sending to the end-user 

2 0 device a response message containing the access control 

information in a header portion and having a content portion 
containing the access control information and also containing 
instructions to send a subsequent request message to another 
network device on a different network domain, the subsequent 
25 message having a content portion containing the at least part 
of access control information; 

wherein in providing non- initial network device 
functionality: 

c) the MDSSO function is adapted to process a request 

3 0 message directed to it containing access control information in 

a content portion by extracting the access control information 
from the content and sending to the end-user device a response 
message containing the access control information in a header 
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portion and having a content portion containing the access 
control information and also containing instructions to send a 
subsequent message to another network device on a different 
network domain, the subsequent message having a content portion 
5 containing at least part of the access control information. 

24 . A network device adapted to implement the method of 

claim 1. 

10 25. A network device adapted to implement the method of 

claim 18. 

26. An article of manufacture comprising: 

a computer usable medium having computer readable 
15 program code means embodied therein for implementing the method 
of claim 1. 

27. A multiple domain single sign-on system comprising a 
plurality of network devices according to claim 23 . 

20 

28. The system of claim 27 wherein each of the plurality 
of network devices identifies a respective another network 
devices in the plurality of network devices. 

25 29. The system of claim 27 wherein each response message 

identifies all remaining unvisited network devices in the 
plurality of network devices. 

30. The system of claim 27 wherein each response message 

3 0 identifies all the network devices in the plurality of network 
devices . 



31. 



An article of manufacture comprising: 
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a computer usable medium having computer readable 
program code means embodied therein for implementing a multiple 
domain single sign-on function, the computer readable code 
means in the article of manufacture comprising: 
5 first computer readable code means adapted to receive 

in a first domain a first request message from a remote device 
and to generate a response message having a content portion, 
the content portion containing access control information and 
containing instructions causing the remote device to access a 
10 network address in a different domain specified in the content 
portion with a subsequent message containing at least part of 
the access control information. 

32. An article of manufacture according to claim 31 
15 further comprising: 

second computer readable code means adapted to 
receive an access request message from the remote device, to 
perform authentication, and to send instructions to the remote 
device to send the first request message to the first computer 
2 0 readable code meams . 

33. An article of manufacture according to claim 32 
wherein the access control information is generated by the 
second computer readable code means, sent to the remote device 

2 5 with the instructions, and then received by the first computer 

readable code means in the first request message. 

34. A computer data signal embodied in a transmission 
medium comprising: 

3 0 a first source code segment adapted to receive at a 

first domain a first request message from a remote device and 
to generate a response message having a content portion, the 
content portion containing access control information and 
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containing instructions to the remote device to access a 
network address at a different domain specified in the content 
portion with a subsequent message containing at least part of 
the access control information. 

5 

35, A method of conveying user-specific information from 

one network device to another network device on a different 
domain through an end user device comprising: 

the one network device in response to a first message 

10 received from the end user device containing user- specif ic 

information, sending a response message to the end user device 
containing the user-specific information, the response message 
being adapted to cause the end user device to send a second 
message to the another network device containing at least part 

15 of the user-specific information after presenting an option to 
the end user device to change and/or delete any of the user- 
specific information; 

wherein the response message has a header portion and 
a content portion and the response message contains the user- 

2 0 specific information and a network device identifier for the 
another network device embedded within its content portion; 

the second message has a header portion and a content 
portion and the second message contains the at least part of 
the user- specif ic information embedded within its content 

2 5 portion. 
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Abstract of the Invention 
Methods and systems are provided which convey access 
control information from a first server to a second server 
through an end user device, for example in a system in which 
these servers and devices are all connected to the Internet. 
The method starts after the first server receives a message 
from the end user device. The first server in response to this 
message from the end user device sends a response message to 
the end user device containing the access control information 
to be conveyed to the second server, optionally after 
performing authentication. The response message also contains 
an instruction for the end user device to post a second message 
to the second server containing the information. The 
information is preferably contained in a content portion of the 
message. A hidden form may be used in the response message to 
contain the information. Optionally, the end user may be 
presented with an option to post the second message or not. 
This may allow conformance with data privacy laws requiring end 
user consent of data transfer. The instruction to post to the 
second server may consist of active content within the response 
message's content portion. This can be used to cause an end 
user device to store a cookie in association with a number of 
servers in different domains thereby implementing a multiple 
domain single sign-on function. 
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prior United States application in the manner provided by the fust paragraph of Title 35, United States 
Code, § 1 12, 1 acknowledge the duty to disclose information which is material to patentability as defined in 
Title 37, Code of Federal PLegulations, § 1.56(a) which became available between the filing date of die prior 
application and the national or PCT international filing date of this application: 

PRIOR U.S. OR PCX APF'LICATION(S) 

Application No. Filing Date Status 

(day/month/year) (pending, abandoned, granted) 



I hereby declare that all statements made herein of my own knowledge are true and that all statements made 
on information and belief £ire believed to be tme; and further that these statements were made with the 
knowledge that wilful false statements and the like so made are punishable by fine or imprisonment, or both, 
under Section 1001 of Tide 18 of the United States Code and that such wilful false statements may 
jeopardize the validity of die application or any patent issued thereon. 

I hereby appoint the following patent agents with full power of substitution, association and revocation to 
prosecute this application and/or international application and to transact all business in the Patent and 
Trademark Office connected therewith: 
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JAMES D. KOKONIS (Reg. No. 21178) 
ALAN R. CAMPBELL (Reg. No. 26129) 
NICHOLAS H. FYFE (Reg. No. 26134) 
ROBERT D. GOULD (Reg. No. 27523) 
THOMAS R. KELLY (Reg. No. 29244) 
MICHAEL E. WHEELER (Reg. No. 29246) 
DONALD F. PHENIX (Reg. No. 32528) 
KOHJI SUZUKI (Reg. No. 44467) 
YWE J. LOOPER (Reg. No. 43758) 
R. JOHN HALEY (Reg. No. 29,502) 
HANS KOENIG (Reg. No. P-46474) 



HUGH 0 'GORMAN (Reg. No. 26140) 
R. ALLAN BRETT (Reg. No. 40476) 
A. DAVID MORROW (Reg. No. 28816) 
JAMES MCGRAW (Reg. No. 28168) 
JOHN BOCHNOVIC (Reg. No. 29229) 
JOY D. MORROW (Reg. No. 3091 1) 
TOKUO HIRAMA (Reg. No. 32551) 
PHILIP D. LAPIN (Reg. No. 44443) 
GRANT W. LYNDS (Reg. No. 44484) 
CHRISTINE N. GENGE (Reg. No. P-45405) 



PLEASE SEND CORRESPONDENCE TO: Customer No. 073 80 
SMART & BIGGAR 
P.O.Box 2999, Station D 
900-55 Metcalfe Street 
Ottawa, Ontario 
Canada KIP 5Y6 
Tel: (613) 232-2486 
Fax: (613) 232-8440 



1) INVENTOR'S SIGNATURE: 
Inventor's Name: Ray 
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_Date: <Ia . 2J) 0 D 
Cheng 



{First) (Middle) 

Country of Citizenship: CANADA 
Residence: Nepean, Ontario, Canada 



{ City, Province, Country) 
Post Office Address: 7 Hobbs Avenue, Nepean, Ontario, Canada K2H 6W7 



2) INVENTOR'S SIGNATURE: 
Inventor's Name: Paul 




Date: J Uj< U TeeO 



Van Oorschot 



(First) (Middle) 

Country of Citizenship: CANADA 

Residence: Ottawa, Ontario, Canada 



(Family Name) 



( City, Province, Country) 
Post Office Addr ess: 1 168 Cameo Drive. Ottawa. Ontario. Canada K2C 1Y7 



3) INVENTOR'S SIGNATURE: 
Inventor's Name: Stephen 



William 



Hillier 



(First) (Middle) 

Country of Citizenship: CANADA 

Residence: Ottawa, Ontario, Canada 



(Family Name) 



(City, Province, Country) 
Post Office Address: 3780 Revelstoke Drive, Ottawa, Ontario, Canada KIV 7C4 



